home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL96.LZH / t0120 / text0007.txt < prev    next >
Encoding:
Text File  |  1996-03-07  |  5.1 KB  |  98 lines
  1.  
  2. Okay, it's time for me again to throw in an idea here... There's been some
  3. discussion back and forth between people about how to best handle the
  4. information interchange between the networking machines, and there's been
  5. quite a few good (And a slightly less amount of bad) suggestions.
  6.  
  7. Now, the networking package could be arranged so that, no matter which
  8. machine initiates the networking sequence (ie, one random machine
  9. initially sends out a networking initiation message throughout the net),
  10. each machine should check its own capabilities to see which one would be
  11. best suited to act as the controlling unit. It would be natural for an
  12. accellerated machine to handle the most CPU-stealing stuff instead on a
  13. standard-configuration Falcon.
  14.  
  15. Therefore, I have made a temporary mental sketch of the initiation
  16. sequence that could be used. Here's the idea.
  17.  
  18. In any given network, be it two players or fifteen, a single machine
  19. should send out a message on the net that a networking game is to be
  20. started. The exact message to be sent does not have to be clear to discuss
  21. this feature - that is a matter for the programmers to decide upon. The
  22. first message should simply be to detect the numer of machines in the
  23. network, and to assign a unique identifier to the diferent machines. (The
  24. machines that initates the sequence could be #0, the next #1,and so on)
  25.  
  26. Following that, a message asking each machine to check the available
  27. hardware should be issued. This should involve a check of drawing speed on
  28. a set area of the playing area, preferably one that involves complex
  29. shapes to _really_ test the frames/second ration. This should take but a
  30. second if the proper code is used. Then the fastest machine is assigned as
  31. the master server, and takes over msot of the network handling. (To make
  32. things easier, if the fastest machine is not the same one that started th
  33. network, assigning new identifiers to each machine, with the new master
  34. being #0 should be considered.
  35.  
  36. Elias suggested that one machine could be selected as host machine and do
  37. nothing but serve the network. This would undoubtedly be a good idea, but
  38. it remains to be seen if it will be necessary. It should be posible to
  39. have a machine act as server and provide a fully playable unslowed game of
  40. Bad Mood, even on an unaccellerated Falcon. But we'll see about that as
  41. the first segments of code are written.
  42.  
  43. Anyway, at this point we will have a working network.
  44.  
  45. Then for the interchange of game information. What we really need to know
  46. is how much information needs to be transferred at the point the game
  47. starts. For each individual player, the absolute minimum would be this:
  48. - Position within the level. This will have to be three words or longwords,
  49.   depending on the nature of the game (I have absolutely no clue!)
  50. - Facing of the player. In which direction is he facing? This is vital to the
  51.   other machines drawing the player's sprite.
  52. - Movement speed. Logical.
  53. - (Optional) Sprite identificator. We might want to use different sprites for
  54.   for each player depending on the weapong he/she wields. It wouldn't be
  55.   the most logical thing if player #2 is using a machine gun but all others
  56.   see him using a scythe, right?
  57. - Additional sprites. If a blowtorch has been fired by the player all others
  58.   should be able to draw the flame, right? This will have to include
  59.   direction and speed of the additional item(s)
  60. - Movement of enemy sprites. It would't be good if ten machines didn't
  61.   synchronize the movement of enemy sprites. The logics included would be
  62.   hilarious, though - Just think of it guys ;-) (This package could get big)
  63.  
  64. There might be more I don't remember. To reduce the networking required,
  65. it would be a good idea to let the master server calculate the AI of the
  66. enemy sprites instead of having all the machines do it individually. That
  67. way the networking load would be reduced and (possibly) the redraw speed
  68. of each individual machine increased, especially if the server does
  69. nothing but maintain the network. I, for one, support the idea, seeing how
  70. it can lessen the load on the other machines.
  71.  
  72. Additional things that the main server should send out include the
  73. following massages:
  74.  
  75. - Resynchronize various elements. We'll find a use for it.
  76. - End of level. One player has reached the end-level switch. Time to move on
  77.   to the next.
  78. - Dead player. Remove sprite from play and replace it with a permanent
  79.   graphical dispay of blood in it's place.
  80. - And maybe more.
  81.  
  82. These are the first ideas. No doubt they will be changed, though I believe
  83. the basic idea might survive the needs of the game. I'm looking forward to
  84. hearing constructive criticism on this one, as well as other ideas.
  85.  
  86. And now for something completely different: When will there be a new beta
  87. version of BM out for the rest of us to see? I'm eager to see how far the
  88. texture-mapping has come!
  89.  
  90. Kai
  91.  
  92. =====================================================================
  93. Kai Trygve Holst           # These are not the views of HiAa - They
  94. P.O.Box 5061, Larsgaarden  # are Copyright (C) 1995, Kai Trygve Holst
  95. N-6021 Aalesund, Norway    # "The fairest rose is picked the first"
  96. http://www.hials.no/~kh/   # "Time is the silentmost enemy of youth"
  97.  
  98.